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Iz 


Introduction 


As discussed in [RFC7379], in a TRILL (Transparent Interconnection of 
Lots of Links) Active-Active Edge (AAE) topology, a Local 
Active-Active Link Protocol (LAALP) -- for example, a Multi-Chassis 
Link Aggregation (MC-LAG) bundle -- is used to connect multiple 
RBridges (Routing Bridges or TRILL switches) to multi-port Customer 
Equipment (CE), such as a switch, virtual switch (vSwitch), or 
multi-port end station. A set of end nodes is attached in the case 
of a switch or vSwitch. It is required that data traffic within a 
specific VLAN from this end node set (including the multi-port 
end-station case) can be ingressed and egressed by any of these 
RBridges simultaneously. End systems in the set can spread their 
traffic among these edge RBridges at the flow level. When a link 
fails, end systems keep using the remaining links in the LAALP 
without waiting for the convergence of TRILL, which provides 
resilience to link failures. 


Since a frame from each end node can be ingressed by any RBridge in 
the local AAE group, a remote edge RBridge may observe multiple 
attachment points (i.e., egress RBridges) for this end node. This 
issue is known as "MAC address flip-flopping"; see [RFC7379] for a 
discussion. 


Per this document, AAE member RBridges use their own nicknames to 
ingress frames into the TRILL campus. Remote edge RBridges are 
required to keep multiple points of attachment per MAC address and 
Data Label (VLAN or Fine-Grained Label [RFC7172]) attached to the 
AAE. This addresses the MAC flip-flopping issue. Using this 
solution, as specified in this document, in an AAE group does not 
prohibit the use of other solutions in other AAE groups in the same 
TRILL campus. For example, the specification in this document and 
the specification in [RFC7781] could be simultaneously deployed for 
different AAE groups in the same campus. 


The main body of this document is organized as follows: Section 2 
lists acronyms and terms. Section 3 describes the overview model. 
Section 4 provides options for incremental deployment. Section 5 
describes how this approach meets the design goals. Section 6 
discusses backward compatibility. Section 7 covers security 
considerations. Section 8 covers IANA considerations. 


Zhang, et al. Standards Track [Page 3] 


RFC 7782 Multi-Attach for Active-Active Edge February 2016 


2. Acronyms and Terminology 
AAE: Active-Active Edge 
Campus: A TRILL network consisting of TRILL switches, links, and 
possibly bridges bounded by end stations and IP routers. For 


TRILL, there is no "academic" implication in the name "campus". 


CE: Customer Equipment (end station or bridge). The device can be 
either physical or virtual equipment. 


Data Label: VLAN or Fine-Grained Label (FGL) 

DRNI: Distributed Resilient Network Interconnect. A link aggregation 
specified in [802.1AX] that can provide an LAALP between (a) one, 
two, or three CEs and (b) two or three RBridges. 


E-L1IFS: Extended Level 1 Flooding Scope 


Edge RBridge: An RBridge providing end-station service on one or more 
of its ports. 


ESADI: End Station Address Distribution Information [RFC7357] 

FGL: Fine-Grained Label [RFC7172] 

FS-LSP: Flooding Scope Link State Protocol Data Unit 

IS: Intermediate System [IS-IS] 

IS-IS: Intermediate System to Intermediate System [IS-IS] 

LAALP: Local Active-Active Link Protocol [RFC7379]. Any protocol 
similar to MC-LAG (or DRNI) that runs in a distributed fashion on 
a CE, on the links from that CE to a set of edge group RBridges, 
and on those RBridges. 

LSP: Link State PDU 

MC-LAG: Multi-Chassis Link Aggregation. Proprietary extensions of 
link aggregation [802.1AX] that can provide an LAALP between one 


CE and two or more RBridges. 


PDU: Protocol Data Unit 


RBridge: A device implementing the TRILL protocol. 
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TRILL: Transparent Interconnection of Lots of Links or Tunneled 
Routing in the Link Layer [RFC6325] [RFC7177]. 
TRILL switch: An alternative name for an RBridge. 


vSwitch: A virtual switch, such as a hypervisor, that also simulates 
a bridge. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


Familiarity with [RFC6325], [RFC6439], and [RFC7177] is assumed in 
this document. 


3. Overview 


Rest of campus 


+ — 


-+-----+--4+-----4+--4+-----4+-4+ 
| RB1 | | RB2 | | RB3 | 
ka NG pa . fa + 

\ | / 
Ned eat 
| | | LAALP1 
|| 
+---+ 
| B | 
+---+ 


H1 H2 H3 H4: VLAN 10 
Figure 1: An Example Topology for TRILL Active-Active Edge 


Figure 1 shows an example network for TRILL AAE (see also Figure 1 in 
[RFC7379]). In this figure, end nodes (H1, H2, H3, and H4) are 
attached to a bridge (B) that communicates with multiple RBridges 
(RB1, RB2, and RB3) via the LAALP. Suppose that RB4 is a "remote" 
RBridge not in the AAE group in the TRILL campus. This connection 
model is also applicable to the virtualized environment where the 
physical bridge can be replaced with a vSwitch while those bare metal 
hosts are replaced with virtual machines (VMs). 
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For a frame received from its attached end node sets, a member 
RBridge of the AAE group conforming to this document always 
encapsulates that frame using its own nickname as the ingress 
nickname, regardless of whether it is unicast or multicast. 


With the two options specified below, even though remote RBridge RB4 
will see multiple attachments for each MAC address from one of the 
end nodes, MAC address flip-flopping will not cause any problems. 


4. Incremental Deployable Options 


This section specifies two options. Option A requires new hardware 
support. Option B can be incrementally implemented throughout a 
TRILL campus with common existing TRILL "fast path" hardware. 
Further details on Option B are given in Section 4.1. 


Option A: 
A new capability announcement would appear in LSPs: "I can cope 
with data-plane learning of multiple attachments for an end node." 
This mode of operation is generally not supported by existing 
TRILL fast path hardware. Only if all edge RBridges to which the 
group has data connectivity — and that are interested in any of 
the Data Labels in which the AAE is interested -- announce this 
capability can the AAE group safely use this approach. If all 
such RBridges do not announce this "Option A" capability, then a 
fallback would be needed, such as reverting from active-active to 
active-standby operation or isolating the RBridges that would need 
to support this capability but do not support it. Further details 
for Option A are beyond the scope of this document, except that, 
as described in Section 4.2, a bit is reserved to indicate support 
for Option A, because a remote RBridge supporting Option A is 
compatible with an AAE group using Option B. 


Option B: 
As pointed out in Section 4.2.6 of [RFC6325] and Section 5.3 of 
[RFC7357], one MAC address may be persistently claimed to be 
attached to multiple RBridges within the same Data Label in the 
TRILL ESADI-LSPs. For Option B, AAE member RBridges make use of 
the TRILL ESADI protocol to distribute multiple attachments of a 
MAC address. Remote RBridges SHOULD disable data-plane MAC 
learning for such multi-attached MAC addresses from TRILL Data 
packet decapsulation, unless they also support Option A. The 
ability to configure an RBridge to disable data-plane learning is 
provided by the base TRILL protocol [RFC6325]. 
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4. 


4. 


Lis 


ts 


Details of Option B 


With Option B, the receiving edge RBridges MUST avoid flip-flop 
errors for MAC addresses learned from the TRILL Data packet 
decapsulation for the originating RBridge within these Data Labels. 
It is RECOMMENDED that the receiving edge RBridge disable data-plane 
MAC learning from TRILL Data packet decapsulation within those 
advertised Data Labels for the originating RBridge, unless the 
receiving RBridge also supports Option A. Alternative 
implementations that produce the same expected behavior, i.e., the 
receiving edge RBridge does not flip-flop among multiple MAC 
attachments, are acceptable. For example, the confidence-level 
mechanism as specified in [RFC6325] can be used. Let the receiving 
edge RBridge give a prevailing confidence value (e.g., 0x21) to the 
first MAC attachment learned from the data plane over others from the 
TRILL Data packet decapsulation. The receiving edge RBridge will 
stick to this MAC attachment until it is overridden by one learned 
from the ESADI protocol [RFC7357]. The MAC attachment learned from 
ESADI is set to have a higher confidence value (e.g., 0x80) to 
override any alternative learning from the decapsulation of received 
TRILL Data packets [RFC6325]. 


1. Advertising Data Labels for Active-Active Edge 


An RBridge in an AAE group MUST participate in ESADI in Data Labels 
enabled for its attached LAALPs. This document further registers two 
data flags, which are used to advertise that the originating RBridge 
supports and participates in an AAE. These two flags are allocated 
from the Interested VLANs Flag Bits that appear in the Interested 
VLANs and Spanning Tree Roots sub-TLV and the Interested Labels Flag 
Bits that appear in the Interested Labels and Spanning Tree Roots 
sub-TLV [RFC7176] (see Section 8.3). When these flags are set to 1, 
the originating RBridge is advertising Data Labels for LAALPs rather 
than plain LAN links. 
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4.1.2. Discovery of Active-Active Edge Members 


Remote edge RBridges need to discover RBridges in an AAE. This is 
achieved by listening to the following "AA LAALP Group RBridges" 
TRILL APPsub-TLV included in the TRILL GENINFO TLV in FS-LSPs 
[RFC7780]: 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type = AA-LAALP-GROUP-RBRIDGES| (2 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Length | (2 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Sender Nickname | (2 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| LAALP ID Size (1 byte) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+ 
| LAALP ID (k bytes) | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+ 


o Type: AA LAALP Group RBridges (TRILL APPsub-TLV type 252) 

o Length: 3 + k 

o Sender Nickname: The nickname the originating RBridge will use as 
the ingress nickname. This field is useful because the 
originating RBridge might own multiple nicknames. 

o LAALP ID Size: The length, k, of the LAALP ID in bytes. 

o LAALP ID: The ID of the LAALP, which is k bytes long. If the 
LAALP is an MC-LAG or DRNI, it is the 8-byte ID, as specified in 
Clause 6.3.2 of [802.1AX]. 

This APPsub-TLV is expected to rarely change, as it only does so in 


cases of the creation or elimination of an AAE group, or of link 
failure or restoration to the CE in such a group. 
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4.1.3. Advertising Learned MAC Addresses 


Whenever MAC addresses from the LAALP of this AAE are learned through 
ingress or configuration, the originating RBridge MUST advertise 
these MAC addresses using the MAC-Reachability TLV [RFC6165] via the 
ESADI protocol [RFC7357]. The MAC-Reachability TLVs are composed in 
a way that each TLV only contains MAC addresses of end nodes attached 
to a single LAALP. Each such TLV is enclosed in a TRILL APPsub-TLVv, 
defined as follows: 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Type = AA-LAALP-GROUP-MAC | (2 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Length | (2 bytes) 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| LAALP ID Size 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| LAALP ID 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| MAC-Reachability TLV 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


(1 byte) 
+-+-+-+-+... +-+- 
(k bytes) 
-+-+-+-+-+-+...+-+- 
(7 + 6*n bytes) 
+-+-+-+-+... +-+- 


+ 


o Type: AA LAALP Group MAC (TRILL APPsub-TLV type 253) 


o Length: The MAC-Reachability TLV [RFC6165] is contained in the 
value field as a sub-TLV. The total number of bytes contained in 
the value field is given by k + 8 + 6*n. 


o LAALP ID Size: The length, k, of the LAALP ID in bytes. 


Oo LAALP ID: The ID of the LAALP, which is k bytes long. Here, it 
also serves as the identifier of the AAE. If the LAALP is an 
MC-LAG (or DRNI), it is the 8-byte ID, as specified in 
Clause 6.3.2 of [802.1AX]. 


o MAC-Reachability sub-TLV: The AA-LAALP-GROUP-MAC APPsub-TLV value 
contains the MAC-Reachability TLV as a sub-TLV (see [RFC6165]; 
n is the number of MAC addresses present). As specified in 
Section 2.2 of [RFC7356], the Type and Length fields of the 
MAC-Reachability TLV are encoded as unsigned 16-bit integers. The 
1-byte unsigned confidence value, along with these TLVs, SHOULD be 
set to prevail over those MAC addresses learned from TRILL Data 
decapsulation by remote edge RBridges. 


This AA-LAALP-GROUP-MAC APPsub-TLV MUST be included in a TRILL 


GENINFO TLV [RFC7357] in the ESADI-LSP. There may be more than one 
occurrence of such TRILL APPsub-TLVs in one ESADI-LSP fragment. 
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For those MAC addresses contained in an AA-LAALP-GROUP-MAC 
APPsub-TLV, this document applies. Otherwise, [RFC7357] applies. 

For example, an AAE member RBridge continues to enclose MAC addresses 
learned from TRILL Data packet decapsulation in MAC-Reachability TLVs 
as per [RFC6165] and advertise them using the ESADI protocol. 


When the remote RBridge learns MAC addresses contained in the 
AA-LAALP-GROUP-MAC APPsub-TLV via the ESADI protocol [RFC7357], it 
sends the packets destined to these MAC addresses to the closest one 
(the one to which the remote RBridge has the least-cost forwarding 
path) of those RBridges in the AAE identified by the LAALP ID in the 
AA-LAALP-GROUP-MAC APPsub-TLV. If there are multiple equal 
least-cost member RBridges, the ingress RBridge is required to select 
one of them in a pseudorandom way, as specified in Section 5.3 of 
[RFC7357]. 


When another RBridge in the same AAE group receives an ESADI-LSP with 
the AA-LAAILP—-GROUP-MAC APPsub-TLV, it also learns MAC addresses of 
those end nodes served by the corresponding LAALP. These MAC 
addresses SHOULD be learned as if those end nodes are locally 
attached to this RBridge itself. 


An AAE member RBridge MUST use the AA-LAALP-GROUP-MAC APPsub-TLV to 

advertise in ESADI the MAC addresses learned from a plain local link 
(a non-LAALP link) with Data Labels that happen to be covered by the 
Data Labels of any attached LAALP. The reason is that MAC learning 

from TRILL Data packet decapsulation within these Data Labels at the 
remote edge RBridge has normally been disabled for this RBridge. 


This APPsub-TLV changes whenever the MAC reachability situation for 
the LAALP changes. 
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4.2. Extended RBridge Capability Flags APPsub-TLV 
The following Extended RBridge Capability Flags APPsub-TLV will be 
included in E-L1FS FS-LSP fragment zero [RFC7780] as an APPsub-TLV of 
the TRILL GENINFO TLV: 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Type = EXTENDED-RBRIDGE-CAP | (2 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Length | (2 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Topology | (2 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
jeju] Reserved | 


$ota—t—t— 4-4-4 ttt tt tit titi t iti ti tat titi titi a 
| Reserved (continued) 
Potato t— tit titi t atti tot aito tito ti tat ita titi t iti ti a 


o Type: Extended RBridge Capability (TRILL APPsub-TLV type 254) 
o Length: Set to 10. 


Oo Topology: Indicates the topology to which the capabilities apply. 
When this field is set to zero, either topologies are not in use 
or the capabilities apply to all topologies [TRILL-MT]. 


o E: Bit 0 of the capability bits. When this bit is set, it 
indicates that the originating RBridge acts as specified in 
Option B above. 


o H: Bit 1 of the capability bits. When this bit is set, it 
indicates that the originating RBridge keeps multiple MAC 
attachments learned from TRILL Data packet decapsulation with fast 
path hardware; that is, it acts as specified in Option A above. 


o Reserved: Flags extending from bit 2 through bit 63 of the 
capability bits. Reserved for future use. These MUST be sent as 
zero and ignored on receipt. 


The Extended RBridge Capability Flags TRILL APPsub-TLV is used to 
notify other RBridges as to whether the originating RBridge supports 
the capability indicated by the E and H bits. For example, if the 

E bit is set, it indicates that the originating RBridge will act as 
defined in Option B. That is, it will disable the MAC learning from 
TRILL Data packet decapsulation within Data Labels advertised by AAE 
RBridges while waiting for the TRILL ESADI-LSPs to distribute the 
{MAC, Nickname, Data Label} association. Meanwhile, this RBridge is 
able to act as an AAE RBridge. It is required that MAC addresses 


Zhang, et al. Standards Track [Page 11] 


RFC 7782 Multi-Attach for Active-Active Edge February 2016 


learned from local LAALPs be advertised in TRILL ESADI-LSPs, using 
the AA-LAALP-GROUP-MAC APPsub-TLV, which is defined in Section 4.1.3. 
If an RBridge in an AAE group, as specified herein, observes a remote 
RBridge interested in one or more of that AAE group’s Data Labels and 
the remote RBridge does not support, as indicated by its extended 
capabilities, either Option A or Option B, then the AAE group MUST 
fall back to active-standby mode. 


This APPsub-TLV is expected to rarely change, as it only needs to be 
updated when RBridge capabilities change, e.g., due to an upgrade or 
reconfiguration. 


5. Meeting the Design Goals 


This section explores how this specification meets the major design 
goals of AAE. 


5.1. No MAC Address Flip-Flopping (Normal Unicast Egress) 


Since all RBridges talking with the AAE RBridges in the campus are 
able to see multiple attachments for one MAC address in ESADI 
[RFC7357], a MAC address learned from one AAE member will not be 
overwritten by the same MAC address learned from another AAE member. 
Although multiple entries for this MAC address will be created, for 
return traffic the remote RBridge is required to consistently use one 
of the attachments for each MAC address rather than flip-flopping 
among them (see Section 4.2.6 of [RFC6325] and Section 5.3 of 
[RFC7357]). 


5.2. Regular Unicast/Multicast Ingress 


LAALP guarantees that each frame will be sent to the AAE via exactly 
one uplink. RBridges in the AAE simply follow the process per 
[RFC6325] to ingress the frame. For example, each RBridge uses its 
own nickname as the ingress nickname to encapsulate the frame. In 
such a scenario, each RBridge takes for granted that it is the 
Appointed Forwarder for the VLANs enabled on the uplink of the LAALP. 


5.3. Correct Multicast Egress 


A fundamental design goal of AAE is that there must be no duplication 
or forwarding loop. 


5.3.1. No Duplication (Single Exit Point) 
When multi-destination TRILL Data packets for a specific Data Label 


are received from the campus, it is important that exactly one 
RBridge out of the AAE group let through each multi-destination 
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packet so that no duplication will happen. The LAALP will have 
defined its selection function (using hashing or an election 
algorithm) to designate a forwarder for a multi-destination frame. 
Since AAE member RBridges support the LAALP, they are able to utilize 
that selection function to determine the single exit point. If the 
output of the selection function points to the port attached to the 
receiving RBridge itself (i.e., the packet should be egressed out of 
this node), the receiving RBridge MUST egress this packet for that 
AAE group. Otherwise, the packet MUST NOT be egressed for that AAE 
group. (For ports that lead to non-AAE links, the receiving RBridge 
determines whether to egress the packet or not, according to 
[RFC6325], which is updated by [RFC7172].) 


5.3.2. No Echo (Split Horizon) 


When a multi-destination frame originated from an LAALP is ingressed 
by an RBridge of an AAE group, distributed to the TRILL network, and 
then received by another RBridge in the same AAE group, it is 

important that this receiving RBridge does not egress this frame back 


to this LAALP. Otherwise, it will cause a forwarding loop (echo). 
The well-known "split horizon" technique (as discussed in 
Section 2.2.1 of [RFC1058]) is used to eliminate the echo issue. 


RBridges in the AAE group need to perform split horizon based on the 
ingress RBridge nickname plus the VLAN of the TRILL Data packet. 

They need to set up per-port filtering lists consisting of the tuple 
of <ingress nickname, VLAN>. Packets with information matching any 
entry in the filtering list MUST NOT be egressed out of that port. 
The information for such filters is obtained by listening to the 
AA-LAALP-GROUP-RBRIDGES TRILL APPsub-TLVs, as defined in 

Section 4.1.2. Note that all enabled VLANs MUST be consistent on all 
ports connected to an LAALP. So, the enabled VLANs need not be 
included in these TRILL APPsub-TLVs. They can be locally obtained 
from the port attached to that LAALP. By parsing these APPsub-TLVs, 
the receiving RBridge discovers all other RBridges connected to the 
same LAALP. The Sender Nickname of the originating RBridge will be 
added to the filtering list of the port attached to the LAALP. For 
example, RB3 in Figure 1 will set up a filtering list that looks like 
{<RB1, VLAN 10>, <RB2, VLAN 10>} on its port attached to LAALP1. 
According to split horizon, TRILL Data packets within VLAN 10 
ingressed by RB1 or RB2 will not be egressed out of this port. 


When there are multiple LAALPs connected to the same RBridge, these 
LAALPs may have VLANs that overlap. Here, a VLAN overlap means that 
this VLAN ID is enabled by multiple LAALPs. A customer may require 
that hosts within these overlapped VLANs communicate with each other. 
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Appendix A provides several scenarios to explain how hosts 
communicate within the overlapped VLANs and how split horizon 
happens. 


4. No Black-Hole or Triangular Forwarding 


If a sub-link of the LAALP fails while remote RBridges continue to 
send packets towards the failed port, a black-hole happens. If the 
AAE member RBridge with that failed port starts to redirect the 
packets to other member RBridges for delivery, triangular forwarding 
occurs. 


The member RBridge attached to the failed sub-link makes use of the 
ESADI protocol to flush those MAC addresses affected by the failure, 
as defined in Section 5.2 of [RFC7357]. After doing that, no packets 
will be sent towards the failed port, and hence no black-hole will 
happen. Nor will the member RBridge need to redirect packets to 
other member RBridges; thus, triangular forwarding is avoided. 


5. Load Balance towards the AAE 


Since a remote RBridge can see multiple attachments of one MAC 
address in ESADI, this remote RBridge can choose to spread the 
traffic towards the AAE members on a per-flow basis. Each of them is 
able to act as the egress point. In doing this, the forwarding paths 
need not be limited to the least-cost path selection from the ingress 
RBridge to the AAE RBridges. The traffic load from the remote 
RBridge towards the AAE RBridges can be balanced based on a 
pseudorandom selection method (see Section 4.1.3). 


Note that the load-balance method adopted at a remote ingress RBridge 
is not to replace the load-balance mechanism of LAALP. These two 
load-spreading mechanisms should take effect separately. 


6. Scalability 


With Option A, multiple attachments need to be recorded for a MAC 
address learned from AAE RBridges. More entries may be consumed in 
the MAC learning table. However, MAC addresses attached to an LAALP 
are usually only a small part of all MAC addresses in the whole TRILL 
campus. As a result, the extra table memory space required by 
multi-attached MAC addresses can usually be accommodated in an 
RBridge’s unused MAC table space. 
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With Option B, remote RBridges will keep the multiple attachments of 
a MAC address in the ESADI link-state databases, which are usually 
maintained by software. In the MAC table, which is normally 
implemented in hardware, an RBridge still establishes only one entry 
for each MAC address. 


6. E-L1IFS Backward Compatibility 


The Extended TLVs defined in Sections 4.1.2, 4.1.3, and 4.2 of this 
document are to be used in an Extended Level 1 Flooding Scope 
(E-L1FS) PDU [RFC7356] [RFC7780]. For those RBridges that do not 
support E-L1FS, the EXTENDED-RBRIDGE-CAP TRILL APPsub-TLV will not be 
sent out either, and MAC multi-attach active-active is not supported. 


7. Security Considerations 


For security considerations pertaining to extensions transported by 
TRILL ESADI, see the Security Considerations section in [RFC7357]. 


For extensions not transported by TRILL ESADI, RBridges may be 
configured to include the IS-IS Authentication TLV (10) in the IS-IS 
PDUs to use IS-IS security [RFC5304] [RFC5310]. 


Since currently deployed LAALPs [RFC7379] are proprietary, security 
over membership in, and internal management of, AAE groups is 
proprietary. In environments where the above authentication is not 
adopted, a rogue RBridge that insinuates itself into an AAE group can 
disrupt end-station traffic flowing into or out of that group. For 
example, if there are N RBridges in the group, it could typically 
control 1/Nth of the traffic flowing out of that group and a similar 
amount of unicast traffic flowing into that group. 


For general TRILL security considerations, see [RFC6325]. 
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8. IANA Considerations 
Brad. TRILL APPsub-TLVs 


IANA has allocated three new types under the TRILL GENINFO TLV 
[RFC7357] for the TRILL APPsub-TLVs defined in Sections 4.1.2, 4.1.3, 
and 4.2 of this document. The following entries have been added to 
the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application 
Identifier 1" registry on the TRILL Parameters IANA web page. 


Type Name Reference 
252 AA-LAALP-GROUP-RBRIDGES RFC 7782 
253 AA-LAALP-—GROUP-MAC RFC 7782 
254 EXTENDED-—RBRIDGE-CAP RFC 7782 


8.2. Extended RBridge Capabilities Registry 
IANA has created a registry under the "Transparent 
Interconnection of Lots of Links (TRILL) Parameters" registry 
as follows: 
Name: Extended RBridge Capabilities 


Registration Procedure: Expert Review 


Reference: RFC 7782 


Bit Mnemonic Description Reference 
0 E Option B Support RFC 7782 
1 H Option A Support RFC 7782 
2-63 = Unassigned 
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8.3. Active-Active Flags 


IANA has 


One flag 


allocated two flag bits, with mnemonic "AA", as follows: 


bit is allocated from the Interested VLANs Flag Bits. 


Mnemonic Description Reference 


AA VLANs for Active-Active RFC 7782 
bit is allocated from the Interested Labels Flag Bits. 
Mnemonic Description Reference 


AA FGLs for Active-Active RFC 7782 
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Appendix A. Scenarios for Split Horizon 


4+------------------ + 4+------------------ + 4+------------------ + 
| RB1 | | RB2 | | RB3 | 
+------------------ + +------------------ + +------------------ + 
L1 L2 fi «1 L2 L3 Li L2 L3 


VL10-20 VL15-25 VL15 VL10-20 VL15-25 VL15 VL10-20 VL15-25 VL15 
LAALP1 LAALP2 LAN LAALP1 LAALP2 LAN LAALP1 LAALP2 LAN 
Bl B2 B10 Bl B2 B20 Bl B2 B30 


Figure 2: An Example Topology to Explain Split Horizon 


Suppose that RB1, RB2, and RB3 are the active-active group connecting 
LAALP1 and LAALP2. LAALPI and LAALP2 are connected to Bl and B2 at 
their other ends. Suppose that all these RBridges use port L1 to 
connect LAALP1 while they use port L2 to connect LAALP2. Assume that 
all three L1 ports enable VLANs 10-20 while all three L2 ports enable 
VLANs 15-25, so that there is an overlap of VLANs 15-20. A customer 
may require that hosts within these overlapped VLANs communicate with 
each other. That is, hosts attached to Bl in VLANs 15-20 need to 
communicate with hosts attached to B2 in VLANs 15-20. Assume that 
the remote plain RBridge RB4 also has hosts attached in VLANs 15-20 
that need to communicate with those hosts in these VLANs attached to 
Bl and B2. 


There are two major requirements: 


1. Frames ingressed from RB1-L1-VLANs 15-20 MUST NOT be egressed out 
of ports RB2-L1 and RB3-Ll. 


2. At the same time, frames coming from B1-VLANs 15-20 should reach 
B2-VLANsS 15-20. 


RB3 stores the information for split horizon on its ports L1 and L2. 


On L1: {<ingress_nickname_RB1, VLANs 10-20>, 
<ingress_nickname_RB2, VLANs 10-20>}. 


On L2: {<ingress_nickname_RB1, VLANs 15-25>, 
<ingress_nickname_RB2, VLANs 15-25>}. 
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Five clarification scenarios follow: 


a. 


Suppose that RB2 or RB3 receives a TRILL multi-destination data 
packet with VLAN 15 and ingress_nickname_RB1. RB3 is the single 
exit point (selected according to the hashing function of LAALP) 
for this packet. On ports Ll and L2, RB3 has covered 
<ingress_nickname_RB1, VLAN 15>, so that RB3 will not egress this 
packet out of either L1 or L2. Here, "split horizon" happens. 


Beforehand, RB1 obtains a native frame on port L1 from B1 in 

VLAN 15. RB1 determines that it should be forwarded as a 
multi-destination packet across the TRILL campus. Also, RB1 
replicates this frame without TRILL encapsulation and sends it out 
of port L2, so that B2 will get this frame. 


Suppose that RB2 or RB3 receives a TRILL multi-destination data 
packet with VLAN 15 and ingress_nickname_RB4. RB3 is the single 
exit point. On ports L1 and L2, since RB3 has not stored any 
tuple with ingress_nickname_RB4, RB3 will decapsulate the packet 
and egress it out of both ports L1 and L2. So, both Bl and B2 
will receive the frame. 


Suppose that there is a plain LAN link port L3 on RB1, RB2, and 
RB3, connecting to B10, B20, and B30, respectively. These L3 
ports happen to be configured with VLAN 15. On port L3, RB2 and 
RB3 store no information for split horizon for AAE (since this 
port has not been configured to be in any LAALP). They will 
egress the packet ingressed from RB1-L1 in VLAN 15. 


If a packet is ingressed from RB1-L1 or RB1-L2 with VLAN 15, 

port RB1-L3 will not egress packets with ingress_nickname_RB1. 
RB1 needs to replicate this frame without encapsulation and sends 
it out of port L3. This kind of "bounce" behavior for 
multi-destination frames is just as specified in paragraph 3 of 
Section 4.6.1.2 of [RFC6325]. 


If a packet is ingressed from RB1-L3, since RB1-L1 and RB1-L2 
cannot egress packets with VLAN 15 and ingress_nickname_RB1, RB1 
needs to replicate this frame without encapsulation and sends it 
out of ports L1 and L2. (Also see paragraph 3 of Section 4.6.1.2 
of [RFC6325].) 
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